1. Field of the Invention
The present invention relates generally to a method of validating a certificate in a public key infrastructure, and more particularly to a method of validating a certificate by a certificate validation server using certificate policies and certificate policy mapping in a public key infrastructure, in which a certificate validation server is constructed in a public key infrastructure to validate a certificate and the certificate is validated using a certificate policy table and a certificate policy mapping table in the certificate validation server.
2. Description of the Prior Art
As the use of the Internet increases and various communication networks are developed, electronic commerce has been rapidly increased, and various transactions have been performed through the Internet and communication networks. However, in a communication network, such as the Internet, a security risk exists due to the risk of leakage of personal information. For example, if the personal information is compromised, a user can suffer serious consequence. Therefore, there is an increased importance of certification and security technologies for increasing security to enable related electronic commerce transactions to be safely and reliably performed between a service provider who provides an electronic commerce service and a user who uses the electronic commerce service.
Currently, for certification and security methods, there are several methods of using a user identification (ID) and a password, physical media, or biometric recognition through fingerprints, handwriting or the like. However, these methods are problematic in that they perform only certification or simply provide limited security, so they cannot perfectly provide sufficient certifications and securities for electronic commerce. For this reason, a public key infrastructure (PKI) is proposed as a standard. In such a PKI scheme, a PKI is constructed such that a reliable certification authority identifies a user and then issues a public key certificate to the user, and the user or opposite user carries out the affixture of an electronic signature and encryption using his personal key or the public key certificate which are kept safe, thus sufficiently solving problems related to certification, integrity and secrecy.
In the PKI, a user performs the validation of a certificate of an opposite party so as to use a public key of the opposite party. In order to validate the certificate, a certification path is first created, and the validation of the created certification path is performed. In this case, the certification path means a certificate chain ranging from a certificate at a trust point which a validator trusts to a certificate which is an object to be validated. That is, a subject of a higher certificate becomes an issuer of a lower certificate, and a last certificate of the certificate chain becomes an object to be validated. The validation of the certification path is a procedure of validating the validities of all certificates on the certification path. Through such certification path validation, the certificate of an opposite party can be verified.
FIG. 1 shows an example of a typical certification path in a PKI domain. The certification path is described with reference to FIG. 1. A validator “A” 10 creates a certificate chain ranging from a certificate of a certification authority (first certification authority) 11, which the validator “A” 10 trusts, to a certificate of a user “B” 14, and validates the certificate chain so as to validate the certificate of the user “B” 14. In this case, the certification path is extended from the first certification authority's certificate to the user “B”'s certificate through a second certification authority's certificate and a third certification authority's certificate.
Currently, a certification path validation procedure in the PKI is defined in the Internet Engineering Task Force (IETF), which manages standards of the Internet technologies, and is based on chapter 12.4.3 of Request For Command (RFC) 2459.
The certification path validation procedure is to validate an identity of a subject, a public key of the subject, and a binding between the attributes of the subject in an object certificate. The certification path must begin at a certificate at a trust point which the validator trusts. Further, in order to validate the certification path, the following requirements must be satisfied.
First, a first certificate on the certification path must be issued by a trusted certification authority. Second, a last certificate must be an object certificate to be validated. Third, the names of an issuer and a subject must form a chain. That is, in all certificates excepting the first and last certificates, a subject of a higher certificate must be an issuer of a next certificate. Fourth, all certificates on the certification path must be valid at the time of validation.
However, the above requirements are only necessary conditions, so basic constraints, name constraints, policy constraints, etc. must be considered to fully validate the certification path.
In the prior art, a client itself performs certificate validation in a PKI. When a second client validates a certificate of a first client in the PKI, certificates of a plurality of certification authorities may exist between a certificate of a certification authority, which the second client trusts, and a certificate of the first client which is an object to be validated. In order to validate the certificate of the first client, the second client must construct a connecting relationship from the certificate of the trusted certification authority to the certificate of the first client to be validated through the certificates of the plural certification authorities, that is, a certification path.
The second client constructs the certification path depending on various trust models. The second client must include certification path constructing modules based on the various trust models in order to construct the certification path. Further, the second client must include module that can construct a certification path on the basis of trust models of other domains in order to compatibly use certificates with other domains. Further, the second client must include modules capable of obtaining certificates of respective domains required to construct the certification path. All modules mentioned above must be installed in the second client.
Further, in the prior art, since the second client performs the certificate validation, it is very difficult or impossible to validate a certificate of another domain in a PKI with a complicated structure comprised of a plurality of certification authorities. Further, when a certificate of another domain is validated, it is difficult to acquire a certificate policy of the domain. Moreover, it is impossible to manage certificate policy mapping between the domain including the second client and another domain, so a problem is caused in using of the policy mapping when a certificate is validated.
Meanwhile, Korean Pat. Appl. No. 2000-65370 filed by Korea Telecom discloses a “System for providing a certification identification service using duplicate electronic signatures” that may be used to provide a transmitter certification service in a PKI under a wireless environment. The system, which provides an end-to-end message security service and a public key based transmitter certification service, provides a certification identification service using duplicate electronic signatures to handle a certificate validating task which is difficult to perform using a wireless terminal with a limited capacity. However, the system is operated only under a wireless environment, and provides only a simple certificate validating function which emphasizes a validity inspection of a certificate under the wireless environment. Therefore, the system does not provide efficiency for certificate validation and does not improve certificate policy management in an overall public key infrastructure.